Johan TORSNER 
Appl. No. 10/572,683 
August 27, 2009 

REMARKS 

Reconsideration and allowance are requested. 

Claims 1-14, 16-25, 27, and 30 stand rejected under 35 U.S.C. §112, second paragraph 
for indefmiteness. This rejection is respectfully traversed. 

Although one of ordinary skill in the art would have understood the meaning of the 
higher RLC layer being higher than the MAC layer, to facilitate prosecution claim 1 is amended 
to recite "receiving at a medium access control layer data units from a radio link control layer 
which is a higher protocol layer than the medium access control layer." 

For claims 16-25 and 27, "the controller" is now referenced as "the medium access 
controller" to provide exact antecedent basis, though it was clear that the medium access 
controller was being referred to simply using "the controller." 

Withdrawal of this rejection is requested. 

The Examiner newly rejects claims 1, 2, 4, 9, 13-16, 18, 23, and 26-30 under 35 U.S.C. 
§102 for anticipation based on newly-applied Terry. This rejection is respectfully traversed. 

"A claim is anticipated only if each and every element as set forth in the claim is found, 
either expressly or inherently described, in a single prior art reference." Verdegaal Bros., Inc. v. 
Union Oil Co,, 814 F,2d 628, 631 (Fed. Cir. 1987). There must be no difference between the 
claimed invention and the reference disclosure, as viewed by a person of ordinary skill in the 
field of the invention. Scripps Clinic &. Research Found, v. Genentech Inc., 927 F.2d 1565, 
1576 (Fed. Cir. 1991). Terry does not satisfy this rigorous standard. 

Terry describes a medium access control (MAC) architecture to reduce transmission 
latency for data block retransmissions. A plurality of data blocks are received and temporarily 
stored in a first buffer and then transmitted. A determination is made as to whether each of the 
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transmitted data blocks was received successfully or needs to be retransmitted. Each transmitted 

data block that needs to be retransmitted is marked and temporarily stored in a second buffer 

having a higher priority than the first buffer. The marked data blocks are retransmitted before 

data blocks stored in the first buffer. 

Regarding claim 1 as an example, Terry fails to disclose " analyzing at the medium access 

control layer some or all of a header of a radio link control data unit associated with the one data 

flow." The Examiner points to [0042] in Terry repeated here for convenience: 

[0042] The present invention implements a method to enable the 
Node B to distinguish the retransmitted PDU from other PDUs. In 
a first embodiment, the RNC 1 02 marks the retransmitted PDU by 
using a field of bits on its Frame Protocol (FP) overheads. The 
retransmitted PDU includes a CmCH-Pi which is updated (or 
increased) every time the PDU is sent (step 1 14) from the RNC 
102 to the Node B 104. This permits the Node B 104 to track the 
number of times the PDU is sent and, therefore, identify the proper 
queue in which to place the PDU. Preferably, the CmCH-Pi is 
typically set and updated at the RNC 102. However, this function 
may also be performed at the Node B 104. The Node B 104 reads 
the CmCH-Pi and determines the proper priority queue for the 
PDU (steps 1 16). The Node B 104 transmission scheduler services 
the higher priority queues in advance of lower priority queues. 
The Node B 1 04 places the PDU to be retransmitted in a buffer 
having a higher priority than it originally had when the PDU was 
originally transmitted as a result of the setting of the CmCH-Pi by 
the RNC 102. 

As Terry explains: "the RNC 102 marks the retransmitted PDU by using a field of bits 
on its Frame Protocol (FP) overheads." The Frame Protocol (FP) overheads are part of the MAC 
header not part of the RLC header as shown for example in Figure 3 of the instant application. 
The CmCH-Pi field in the retransmitted PDU is part of the MAC-hs data unit header. See also 
USPA 2008/0298323 in Figure 6 and [0049]~[0050] as well as 3GPP TS 25.425 v8.3.0 (2009-06) 
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at 6.2.4. The latter may be located at the following link: http ://www3 gpp.org/frp/Specs/html- 
info/25425.htm . 

So Terry describes the MAC layer analyzing the MAC header and not the RLC header. 
As a result, the above-quoted claim feature is missing, and the anticipation rejection is in error. 

Applicants note Terry's assumption in paragraph [0038]: "Since the MAC-d PDU 
contains exactly 1 RLC PDU (plus other potential MAC information), a MAC-d PDU can be 
considered equivalent to a RLC PDU. Although, discussion of PDUs in the CRNC or the Node 
B in the present application refers to MAC-d PDUs (not RLC PDUs), they can be considered 
equivalent for the purpose of the present invention and the term PDU will be used hereinafter to 
refer to both." But the fact is that the header of a MAC-d PDU is not the same as the header of 
to a RLC PDU. There simply is no teaching in Terry that the MAC layer looks and is aware of 
the substantive contents of the RLC header. 

Normally, the MAC layer simply encapsulates the entire RLC data unit along with its 
RLC header and attaches its own MAC layer header. Terry's approach is consistent with the 
normal goal of the OS1 and other protocol stacks which is to eliminate the need for each layer to 
be aware of and analyze the content of the data units received from another layer. But the 
inventors in this application were mindful of the PDU priority problem described in the 
background of this application. Although the priority levels for different types of RLC PDUs in 
a data flow could be signaled over the Iub interface as part of the frame handling protocol, e.g., a 
2-bit field indicating the PDU priority could be sent between the RNC and the Node B, this 
approach requires additional signaling from the RNC to the Node B. That extra signaling is 
avoided in the approach of claim 1 by the Node B analyzing and classifying RLC PDUs based on 
content in the RLC PDU header. Even though the node B normally does not contain any RLC 
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"awareness," that RLC awareness implemented in the Node B allows the Node B to check some 
or all of the existing RLC PDU header and/or RLC payload in order to make priority decisions 
for transmission. Terry simply does not do this. 

Claims 3 and 1 7 stand rejected for obviousness based on Terry and Itoh. Paragraph 
[0225] in Itoh relates to a method for ensuring video quality by prioritizing the transmission of 
control packets. Figure 27 simply shows two priority level adding block 2703 and 2707 for 
adding a high priority level to control packets and a low priority level to data packets. An 
example of a method for adding priority level is to enter priority level information into the TOS 
field of IP packets. There is no discussion of an RLC layer or RLC header or of a MAC layer 
analyzing an RLC header. The Examiner should note that the determining step of claim 3 is part 
of the analyzing step of claim 1 : "analyzing at the medium access control layer some or all of a 
header of a radio link control data unit associated with the one data flow." So even if Terry and 
Itoh couid be combined for purposes of argument, that combination fails to teaching the 
analyzing step of claim 1 or the further determining steps of claim 3. 

Although the Examiner applies several other secondary references along with Terry, none 
of them remedy the basic deficiencies of Terry as noted above. 

The application is in condition for allowance. An early notice to that effect is solicited. 



- 11 - 



1506201 



Johan TORSNER 
Appl.No. 10/572,683 
August 27, 2009 



JRL:maa 

901 North Glebe Road, 1 1th Floor 
Arlington, VA 22203-1808 
Telephone: (703)816-4000 
Facsimile: (703) 816-4100 



Respectfully submitted, 
NIXON & VANDERHYE P.C. 



By: /John R. Lastova/ 

John R. Lastova 
Reg. No. 33,149 



- 12- 



1506201 



